A System Center Configuration Manager 2007 (ConfigMgr) hotfix will affect one or more separate roles within the distributed environment. Possible roles include:
· Primary Site Server
· Secondary Site Server
· Remote Administrator Console
· Remote Provider
· Client
This article is designed to provide general guidance as it relates to ConfigMgr hotfixes. For details on a specific hotfix refer to its accompanying Knowledge Base (KB) article at http://support.microsoft.com.
Hotfix Basics
Regardless of the affected roles, only a single bundle is released. The bundle, when distributed via Microsoft Customer Service and Support (CSS) or directly via the Knowledge Base article (KB article), will be packaged using the Microsoft Hotfix Self-Extractor.
The name of this executable file will be:
<FixID>_<Language>_<Platform>_zip.exe
Note that the FixID value is an internal reference number separate from the KB article ID.
420401_ENU_i386_zip.exe is one example.
The platform identifier is not relevant for a ConfigMgr SP2 or higher hotfix; the same file will extract on both 32-bit and 64-bit platforms.
The self-extracting file can be run on any machine and will display a prompt to choose a location to extract the contents which will be the actual hotfix bundle.
With the release of Service Pack 2 (SP2) for ConfigMgr, this bundle is a Windows Installer .MSI file. Prior to SP2 the bundle was built using Update.exe.
The .MSI is named according to the following convention:
<Product>-<Affected Service Pack >-<KB Article ID>-<Language>.MSI
For example, SCCM2007-SP2-KB2263826-ENU.MSI is the ConfigMgr 2007 post SP2 English version of the fix from KB2263826. Some early post-SP2 hotfixes also contained an x86 identifier in the name, but this was not relevant as the x86 file worked on either platform.
If a hotfix is released as a general update and made available for download from the Microsoft Download Center it will be in the .MSI format; the hotfix self-extractor is not used.
The KB article for a given hotfix will list the applicable roles. If you attempt to install a hotfix on a machine that does not contain one of those roles you would see the message:
This hotfix doesn’t match the installed role of Configuration Manager 2007
International environments and localized hotfixes
Hotfixes will be available in the localized server languages, or in the case of clients in one of the two International Client Packs (ICPs). An ICP version of a hotfix only affects the client binaries but will still be applied to the site server. Once an ICP has been installed on a site it also changes the version number. The end result is that ICP versions of hotfixes will need to be applied for those clients in the future. To confirm the ICP version of a site server check the Full Version value in the following registry key:
Software\[Wow6432Node]\Microsoft\SMS\Setup\
The value should be in the format of 04.00.XXXX.YZZZ
Where XXXX is the build number (6487 for ConfigMgrSP2), Y is the service pack number, and ZZZ the QFE version.
QFE versions are 000 for ENU or other localize language, 400 for ICP1 and 700 for ICP2. So for ConfigMgrSP2 ICP1 the version would be 04.00.6487.2400 and ICP2 is 04.00.6487.2700.
For more information refer to Supported Localized Languages and Tasks for International and Multi-Language Configuration Manager Clients.
Non-client Hotfix Installation (SP2)
With the exception of a ConfigMgr client, the hotfix .MSI file should be installed directly to the machine housing the applicable role. This includes Administrator Console machines and remote Provider servers.
In the case of a hotfix that applies to both primary and secondary sites, it is possible the same files will not be updated on the secondary site. This is only done when a hotfix contains a file that isn’t applicable to a secondary site, such as dataldr.dll, and is usually referenced in the KB article.
Remote site systems, such as a remote Management Point or State Migration Point, are updated by installing the hotfix on their respective site server.
Some components on a site server or remote site system will be reinstalled depending on the roles to be updated. Progress can be tracked using the <ConfigMgr Install Folder>\Logs\sitecomp.log file. This is a process similar to performing a Site Reset. All components that are installed on a server housing the affected role will be reinstalled.
For example, take a case where SiteServer1 has the Management Point installed and RemoteServer1 has the State Migration Point (SMP). A hotfix affecting only the SMP will result in that component being reinstalled on RemoteServer1, with no direct impact to running components on SiteServer1.
Administrator customizable files, such as sms_def.mof or AdminConsole.xml may be replaced by some hotfixes. When this happens it should be noted in the KB article, and the files will be backed up to %Windir%\$NTUninstall<KB Article ID>\,e.g., C:\Windows\NtUninstallKB955262$\. Any changes made by the administrator will need to be merged from the backup to the file supplied with the hotfix and then tested.
Any required database updates are applied by running an update.sql file automatically as part of the installation process. This file will also be placed in the <ConfigMgr Install Folder>\Logs\<KB Article ID>\ folder.
The reset of site components and running of the update.sql script can be bypassed using the switched noted below.
Other actions taken during the hotfix installation will be captured in the %temp%\MSI*.log file created during installation. Separate logging for the MSI file can be accomplished via global Windows Installer Logging policies, or directly via the command line as noted below:
msiexec.exe /I <Product.msi> /L*v <logfilename> [/Quiet] [NODBUPGRADE=1] [NOSITERESET=1] [NOADVCLIPACKAGE)=1]
Where:
/Quiet: Unattended installation mode; no UI
NODBUPGRADE=1: Will not run the update.sql script to update the database/
NOSITERESET=1: Will not perform site reset; this could result in remote site systems not updating until manually reset at a later time.
NOADVCLIPACKAGE=1: Won’t launch the wizard to automatically create a package & program to update clients.
Once a server hotfix has been deemed relevant to a given operating environment, we recommend applying the hotfix to all site servers to maintain consistency once you have completed testing and confirmed it resolved the issue. Targeting the servers can be done via inventory based collections using file details from the KB article, or other methods as needed in your environment.
Non-client Hotfix Installation (Pre-SP2)
Prior to the release of SP2, Configuration Manager 2007 hotfixes were built using Microsoft’s Update.exe technology instead of Windows Installer. The primary functional difference was that if a hotfix contained a SQL script (update.sql) it would have to be run manually against the site database server.
Client Hotfix Installation
A Configuration Manager Client hotfix is comprised of a Windows Install Patch (.MSP) file which will update the necessary binaries when applied to a client.
This file is contained within the original hotfix .MSI file, which in turn must be installed on a site server.
The .MSI will move the client patch to the \<Configuration Manager Install Folder>\client\<platform>\hotfix\KBxxxxxx\ folder on the site server.
In addition it will by default launch a wizard to guide you through the creation of a package and program to distribute the patch to client machines. This is recommended but can be skipped by using the NOADVCLIPACKAGE switch noted previously.
Note If the wizard is bypassed, or another deployment method such as System Center Updates Publisher (SCUP) is used, the command line should be structured as follows:
msiexec.exe /p <patchname.msp> /L*v %TEMP%\<logname.log> /q REINSTALL=ALL REINSTALLMODE=mous
e.g. msiexec.exe /p sccm2007ac-sp2-kb2261172-x86.msp /L*v %TEMP%\sccm2007ac-sp2-kb2261172-x86.msp.LOG /q
Note The REINSTALL=ALL REINSTALLMODE=mous parameters are required.
When defining the remaining program properties the following parameters should also be set:
Run with Administrative rights
Run Minimized
After Running: Program Restarts Computer; this is needed to ensure that any status MIF files are collected after a restart of the client service (ccmexec.exe). No actual restart of the computer should occur.
Note In either case – using the wizard or manually creating the command line – any parameters previously sent to the client.msi file should be resupplied for the patch.
For example if the Fallback Status Point (FSP) and Server Locator Point (SLP) were originally supplied during client installation, the patch command line should be modified to include those.
Modifying the previous example this would be:msiexec.exe /p <patchname.msp> /L*v %TEMP%\<logname.log> /q REINSTALL=ALL REINSTALLMODE=mous FSP=SMSFP01 SMSSLP=SMSSLP01where SMSFP01 and SMSSLP01 are the names of the FSP and SLP respectively.
Do not attempt to install a patch file directly on a client, such as by right-clicking the .MSP file and selecting “Install”. Doing so prevents you from specifying required command line parameters. Applying a patch with this method is not supported and may prevent future hotfixes from properly installing.
In addition it is not supported to apply the patch directly to the client.msi file (slipstream). This too may cause unexpected issues on the client and prevent future servicing.
If a hotfix needs to be applied during the initial installation of the ConfigMgr client, this can be accomplished using the PATCH= installation property. For more information refer to http://support.microsoft.com/kb/907423; while written for Systems Management Server 2003 the article also applies to ConfigMgr 2007.
Further details associated with the wizard will be noted in a text file copied to the <ConfigMgr Install Folder>\Logs\<KB Article ID>\ACReadme.txt file on the site server.
The wizard launched from the .MSI will create a package a program, but will not create a query or collection for use in distributing the hotfix. Possibilities for creating these include querying inventory data for specific file versions, or building queries based on client component versions. File version data is documented in the File information section of the KB article. Client component versions can be seen via hardware inventory data or manually checking the properties in the client control panel applet. Components may include the CcmFramework, CCMPolicyAgeny,SMSInventory or others. Refer to the ACReadme.txt file that is bundled with client side hotfixes for a more complete list of components.
Below is an example of a query that assumes the CCM Framework component was updated to version 4.00.7487.2012 by a hotfix. This query could then be used as the basis for a collection to target the hotfix.
select * from SMS_R_System
inner join SMS_G_System_SMS_ADVANCED_CLIENT_STATE
on SMS_G_System_SMS_ADVANCED_CLIENT_STATE.ResourceID = SMS_R_System.ResourceId
where SMS_R_System.ClientType = 1
and SMS_G_System_SMS_ADVANCED_CLIENT_STATE.Name = "CcmFramework"
and (SMS_G_System_SMS_ADVANCED_CLIENT_STATE.Version < "4.00.6487.2012"
In summary, a hotfix .MSI file should be run on the affected computer except in the case of a client. In that scenario the .MSI file must be run on a site server, and the .MSP file then distributed to affected clients.Summary
This article will be updated with additional information as needed to reflect any version specific changes or other details related to applying Configuration Manager 2007 hotfixes.
· Primary Site Server
· Secondary Site Server
· Remote Administrator Console
· Remote Provider
· Client
This article is designed to provide general guidance as it relates to ConfigMgr hotfixes. For details on a specific hotfix refer to its accompanying Knowledge Base (KB) article at http://support.microsoft.com.
Hotfix Basics
Regardless of the affected roles, only a single bundle is released. The bundle, when distributed via Microsoft Customer Service and Support (CSS) or directly via the Knowledge Base article (KB article), will be packaged using the Microsoft Hotfix Self-Extractor.
The name of this executable file will be:
<FixID>_<Language>_<Platform>_zip.exe
Note that the FixID value is an internal reference number separate from the KB article ID.
420401_ENU_i386_zip.exe is one example.
The platform identifier is not relevant for a ConfigMgr SP2 or higher hotfix; the same file will extract on both 32-bit and 64-bit platforms.
The self-extracting file can be run on any machine and will display a prompt to choose a location to extract the contents which will be the actual hotfix bundle.
With the release of Service Pack 2 (SP2) for ConfigMgr, this bundle is a Windows Installer .MSI file. Prior to SP2 the bundle was built using Update.exe.
The .MSI is named according to the following convention:
<Product>-<Affected Service Pack >-<KB Article ID>-<Language>.MSI
For example, SCCM2007-SP2-KB2263826-ENU.MSI is the ConfigMgr 2007 post SP2 English version of the fix from KB2263826. Some early post-SP2 hotfixes also contained an x86 identifier in the name, but this was not relevant as the x86 file worked on either platform.
If a hotfix is released as a general update and made available for download from the Microsoft Download Center it will be in the .MSI format; the hotfix self-extractor is not used.
The KB article for a given hotfix will list the applicable roles. If you attempt to install a hotfix on a machine that does not contain one of those roles you would see the message:
This hotfix doesn’t match the installed role of Configuration Manager 2007
International environments and localized hotfixes
Hotfixes will be available in the localized server languages, or in the case of clients in one of the two International Client Packs (ICPs). An ICP version of a hotfix only affects the client binaries but will still be applied to the site server. Once an ICP has been installed on a site it also changes the version number. The end result is that ICP versions of hotfixes will need to be applied for those clients in the future. To confirm the ICP version of a site server check the Full Version value in the following registry key:
Software\[Wow6432Node]\Microsoft\SMS\Setup\
The value should be in the format of 04.00.XXXX.YZZZ
Where XXXX is the build number (6487 for ConfigMgrSP2), Y is the service pack number, and ZZZ the QFE version.
QFE versions are 000 for ENU or other localize language, 400 for ICP1 and 700 for ICP2. So for ConfigMgrSP2 ICP1 the version would be 04.00.6487.2400 and ICP2 is 04.00.6487.2700.
For more information refer to Supported Localized Languages and Tasks for International and Multi-Language Configuration Manager Clients.
Non-client Hotfix Installation (SP2)
With the exception of a ConfigMgr client, the hotfix .MSI file should be installed directly to the machine housing the applicable role. This includes Administrator Console machines and remote Provider servers.
In the case of a hotfix that applies to both primary and secondary sites, it is possible the same files will not be updated on the secondary site. This is only done when a hotfix contains a file that isn’t applicable to a secondary site, such as dataldr.dll, and is usually referenced in the KB article.
Remote site systems, such as a remote Management Point or State Migration Point, are updated by installing the hotfix on their respective site server.
Some components on a site server or remote site system will be reinstalled depending on the roles to be updated. Progress can be tracked using the <ConfigMgr Install Folder>\Logs\sitecomp.log file. This is a process similar to performing a Site Reset. All components that are installed on a server housing the affected role will be reinstalled.
For example, take a case where SiteServer1 has the Management Point installed and RemoteServer1 has the State Migration Point (SMP). A hotfix affecting only the SMP will result in that component being reinstalled on RemoteServer1, with no direct impact to running components on SiteServer1.
Administrator customizable files, such as sms_def.mof or AdminConsole.xml may be replaced by some hotfixes. When this happens it should be noted in the KB article, and the files will be backed up to %Windir%\$NTUninstall<KB Article ID>\,e.g., C:\Windows\NtUninstallKB955262$\. Any changes made by the administrator will need to be merged from the backup to the file supplied with the hotfix and then tested.
Any required database updates are applied by running an update.sql file automatically as part of the installation process. This file will also be placed in the <ConfigMgr Install Folder>\Logs\<KB Article ID>\ folder.
The reset of site components and running of the update.sql script can be bypassed using the switched noted below.
Other actions taken during the hotfix installation will be captured in the %temp%\MSI*.log file created during installation. Separate logging for the MSI file can be accomplished via global Windows Installer Logging policies, or directly via the command line as noted below:
msiexec.exe /I <Product.msi> /L*v <logfilename> [/Quiet] [NODBUPGRADE=1] [NOSITERESET=1] [NOADVCLIPACKAGE)=1]
Where:
/Quiet: Unattended installation mode; no UI
NODBUPGRADE=1: Will not run the update.sql script to update the database/
NOSITERESET=1: Will not perform site reset; this could result in remote site systems not updating until manually reset at a later time.
NOADVCLIPACKAGE=1: Won’t launch the wizard to automatically create a package & program to update clients.
Once a server hotfix has been deemed relevant to a given operating environment, we recommend applying the hotfix to all site servers to maintain consistency once you have completed testing and confirmed it resolved the issue. Targeting the servers can be done via inventory based collections using file details from the KB article, or other methods as needed in your environment.
Non-client Hotfix Installation (Pre-SP2)
Prior to the release of SP2, Configuration Manager 2007 hotfixes were built using Microsoft’s Update.exe technology instead of Windows Installer. The primary functional difference was that if a hotfix contained a SQL script (update.sql) it would have to be run manually against the site database server.
Client Hotfix Installation
A Configuration Manager Client hotfix is comprised of a Windows Install Patch (.MSP) file which will update the necessary binaries when applied to a client.
This file is contained within the original hotfix .MSI file, which in turn must be installed on a site server.
The .MSI will move the client patch to the \<Configuration Manager Install Folder>\client\<platform>\hotfix\KBxxxxxx\ folder on the site server.
In addition it will by default launch a wizard to guide you through the creation of a package and program to distribute the patch to client machines. This is recommended but can be skipped by using the NOADVCLIPACKAGE switch noted previously.
Note If the wizard is bypassed, or another deployment method such as System Center Updates Publisher (SCUP) is used, the command line should be structured as follows:
msiexec.exe /p <patchname.msp> /L*v %TEMP%\<logname.log> /q REINSTALL=ALL REINSTALLMODE=mous
e.g. msiexec.exe /p sccm2007ac-sp2-kb2261172-x86.msp /L*v %TEMP%\sccm2007ac-sp2-kb2261172-x86.msp.LOG /q
Note The REINSTALL=ALL REINSTALLMODE=mous parameters are required.
When defining the remaining program properties the following parameters should also be set:
Run with Administrative rights
Run Minimized
After Running: Program Restarts Computer; this is needed to ensure that any status MIF files are collected after a restart of the client service (ccmexec.exe). No actual restart of the computer should occur.
Note In either case – using the wizard or manually creating the command line – any parameters previously sent to the client.msi file should be resupplied for the patch.
For example if the Fallback Status Point (FSP) and Server Locator Point (SLP) were originally supplied during client installation, the patch command line should be modified to include those.
Modifying the previous example this would be:msiexec.exe /p <patchname.msp> /L*v %TEMP%\<logname.log> /q REINSTALL=ALL REINSTALLMODE=mous FSP=SMSFP01 SMSSLP=SMSSLP01where SMSFP01 and SMSSLP01 are the names of the FSP and SLP respectively.
Do not attempt to install a patch file directly on a client, such as by right-clicking the .MSP file and selecting “Install”. Doing so prevents you from specifying required command line parameters. Applying a patch with this method is not supported and may prevent future hotfixes from properly installing.
In addition it is not supported to apply the patch directly to the client.msi file (slipstream). This too may cause unexpected issues on the client and prevent future servicing.
If a hotfix needs to be applied during the initial installation of the ConfigMgr client, this can be accomplished using the PATCH= installation property. For more information refer to http://support.microsoft.com/kb/907423; while written for Systems Management Server 2003 the article also applies to ConfigMgr 2007.
Further details associated with the wizard will be noted in a text file copied to the <ConfigMgr Install Folder>\Logs\<KB Article ID>\ACReadme.txt file on the site server.
The wizard launched from the .MSI will create a package a program, but will not create a query or collection for use in distributing the hotfix. Possibilities for creating these include querying inventory data for specific file versions, or building queries based on client component versions. File version data is documented in the File information section of the KB article. Client component versions can be seen via hardware inventory data or manually checking the properties in the client control panel applet. Components may include the CcmFramework, CCMPolicyAgeny,SMSInventory or others. Refer to the ACReadme.txt file that is bundled with client side hotfixes for a more complete list of components.
Below is an example of a query that assumes the CCM Framework component was updated to version 4.00.7487.2012 by a hotfix. This query could then be used as the basis for a collection to target the hotfix.
select * from SMS_R_System
inner join SMS_G_System_SMS_ADVANCED_CLIENT_STATE
on SMS_G_System_SMS_ADVANCED_CLIENT_STATE.ResourceID = SMS_R_System.ResourceId
where SMS_R_System.ClientType = 1
and SMS_G_System_SMS_ADVANCED_CLIENT_STATE.Name = "CcmFramework"
and (SMS_G_System_SMS_ADVANCED_CLIENT_STATE.Version < "4.00.6487.2012"
In summary, a hotfix .MSI file should be run on the affected computer except in the case of a client. In that scenario the .MSI file must be run on a site server, and the .MSP file then distributed to affected clients.Summary
This article will be updated with additional information as needed to reflect any version specific changes or other details related to applying Configuration Manager 2007 hotfixes.